gITF 2.0 Quick Reference Guide 


gITF was designed and specified by the Khronos® 
Group, for the efficient transfer of 3D content 
over networks. 


The core of gITF is a JSON file that describes the 
structure and composition of a scene containing 
3D models. The top-level elements of this file are: 


scenes, nodes 
Basic structure of the scene 


cameras 
View configurations for the scene 


meshes 
Geometry of 3D objects 


buffers, bufferViews, accessors 
Data references and data layout descriptions 


materials 
Definitions of how objects should be rendered 


textures, images, samplers 
Surface appearance of objects 


skins 
Information for vertex skinning 


animations 
Changes of properties over time 


These elements are contained in arrays. References 
between the objects are established by using their 
indices to look up the objects in the arrays. 


It is also possible to store the whole asset in a single 
binary gITF file. In this case, the JSON data is stored 


as a String, followed by the binary data of buffers 
or images. 


Further resources 


The Khronos gITF landing page: 
https://www.khronos.org/gltf 


KHROONOS 


GRO U P 
CONNECTING SOFTWARE TO SILICON 
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The Khronos gITF GitHub repository: 
https://github.com/KhronosGroup/gITF 


ITF 
a 


Concepts 


The conceptual relationships between the top-level 
elements of a gITF asset are shown here: 


scene 


v 


node 


v 


mesh 


v 


material accessor <€ animation 


v v 


texture bufferView 


v v 


image buffer 


skIN 


Sampler 


Binary data references 


The images and buffers of a gITF asset may refer to 
external files that contain the data that are required 
for rendering the 3D content: 


"buffers": [ The buffers refer to binary 
{ files (.BIN) that contain 
"uri": "buffer01.bin" : : 
geometry- or animation 
"byteLength": 102040, 
} data. 


ne The images refer to image 
{ files (PNG, JPG...) that 
"uri": “image0l.png" Contain texture data for 
1, the models. 


The data is referred to via URIs, but can also be 
included directly in the JSON using data URIs. The 
data URI defines the MIME type, and contains the 
data as a base64 encoded string: 


Buffer data: 


"data: application/gltf-buffer ;base64,AAABAATAAgA..." 


Image data (PNG): 


"data: image/png; base64,iVBORWOK..." 


Version 2.0b 
gITF version 2.0 
This overview is 
non-normative! 


Feedback: 
gltf@marco-hutter.de 


QUES. 


©2016-2019 Marco Hutter 
www.marco-hutter.de 


gITF and the gITF logo 
are trademarks of the 
Khronos Group Inc. 
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scenes, nodes 


The gITF JSON may contain scenes (with an optional 
default scene). Each scene can contain an array of 
indices of nodes. 


"scene": 0, Each of the nodes can 
"scenes": [ contain an array of indices 
t of its children. This allows 
"nodes": [ 0, 2 ] é : 
} modeling a simple scene 


ir hierarchy: 
"nodes": [ 


{ 


"children": 


"nodes": [ A node may contain a local 
{ transform. This can be given as 
bea ! a column-major matrix array, 
10,0, or with separate translation, 
0,1,0, rotation and scale properties, 
,6,7,1 where the rotation is given as a 
!, quaternion. The local transform 
1. matrix is then computed as 
a M=T*R*S 
"translation": where T, Rand S are the matrices 
[ 0,0,0 ], that are created from the 
ae translation, rotation and scale. 
ee. |!" The global transform of a node 
ales) is given by the product of all local 
transforms on the path from the 


y y 


ue root to the respective node. 


Each node may referto a mesh or "nodes": [ 
a Camera, using indices that point { 
into the meshes and cameras arrays. 
These elements are then attached 
to these nodes. During rendering, { 

instances of these elements are "camera": 2, 
created and transformed with the 
global transform of the node. 


"mesh": 4, 


] 

The translation, rotation and scale properties of a 
node may also be the target of an animation: The 
animation then describes how one property 
changes over time. The attached objects will move 
accordingly, allowing to model moving objects or 
camera flights. 


Nodes are also used in vertex skinning: A node 
hierarchy can define the skeleton of an animated 
character. The node then refers to a mesh and to 
a skin. The skin contains further information about 
how the mesh is deformed based on the current 
Skeleton pose. 
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meshes 
The meshes may contain multiple mesh primitives. 
These refer to the geometry data that Is required 
for rendering the mesh. 
eenesu ony Each mesh primitive has a 
{ rendering mode, which is 
"primitives": [ a constant indicating whether 
arene it should be rendered as 
findiccey: On POINTS, LINES, Of TRIANGLES. 
"attributes": { The primitive also refers to 
"POSITION": 1, jndices and the attributes 
of the vertices, using the 
= indices of the accessors for 
this data. The material that 
Should be used for rendering 
is also given, by the index of 
the material. 


Each attribute is defined by mapping the attribute 
name to the index of the accessor that contains the 
attribute data. This data will be used as the vertex 
attributes when rendering the mesh. The attributes 
may, for example, define the POSITION and the 
NORMAL of the vertices: 


POSITION ie 
NORMAL [oma] 0.71] 0.0 | 


(2,7. =1s8) 6.2) 
(0.71 20. 71-1040) 


Position: (1.2, 
Normal: 


A mesh may define multiple morph targets. Such 
a morph target describes a deformation of the 
Original mesh. 
7 ere ae To define a mesh with morph 
primitives": [ te en 
f targets, each mesh primitive 
_ can contain an array of 
ae [ targets. These are dictionaries 
iene pe EL that map names of attributes 
syoleinee Le to the indices of accessors that 
Me contain the displacements of 


the geometry for the target. 
"POSITION": 21, 


"NORMAL": 23 The mesh may also contain an 
} array of weights that define 
‘ the contribution of each morph 
1, target to the final, rendered 
"weights": [0, 0.5] State of the mesh. 
} 


Combining multiple morph targets with different 
weights allows, for example, modeling different 
facial expressions of a character: The weights can 
be modified with an animation, to interpolate 
between different states of the geometry. 
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buffers, bufferViews, accessors 


The buffers contain the data that is used for the 
geometry of 3D models, animations, and skinning. 
The bufferViews add structural information to this 
data. The accessors define the exact type and 
layout of the data. 
"buffers": [ Each of the buffers refers 
{ to a binary data file, using 
weve wecpeeror pinw 2 URI. It is the source of 
one block of raw data with 
the given byteLength. 


Each of the bufferViews 
"bufferViews": [ 

f refers to one buffer. It 
"buffer": 0, has a byteOffset anda 
"byteOffset": byteLength, defining the 
ine Saar ra part of the buffer that 
eens a4o6a) belongs to the bufferView, 

and an optional OpenGL 
buffer target. 


4, 


"accessors": | The accessors define how 
{ the data of a bufferView is 
feeder esis interpreted. They may 
"byteOffset": 4, : St 
"type": "VEC2", define an additional 
"componentType" : byteOffset referring to the 
"count": 2, start of the bufferView, 
jee ee ae and contain information 
See: about the type and layout 
] of the bufferView data: 


The data may, for example, be defined as 2D vectors 
of floating point values when the type is "VEC2" 

and the componenttType is GL_FLOAT (5126). The 
range of all values is stored in the min and max 
property. 

The data of multiple accessors may be interleaved 
inside a bufferView. In this case, the bufferView will 
have a byteStride property that says how many 
bytes are between the start of one element of an 
accessor, and the start of the next. 


5126, 


The buffer data is read from a file: 


0 4 8 16 20 


buffer 
byteLength = 35 


The bufferView defines a segment of the buffer data: 


bufferView 4 8 12 16 20 
byteOffset = 4 


byteLength = 28 
The accessor defines an additional offset: 


accessor 8 12 16 20 


byteOffset = 4 


byteStride = 12 


type = "VEC2" 
componenttType = GL_FLOAT 


Bem eas 
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COUT TTT TTT 
COUT TTT 


The bufferView defines a stride between the elements: 


8 12 16 20 24 28 


The accessor defines that the elements are 2D float vectors: 
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Sparse accessors 


When only few elements of an accessor differ from 
a default value (which is often the case for morph 
targets), then the data can be given in a very 
compact form using a sparse data description: 


"accessors": [ The accessor defines the 
{ type of the data (here, 
PENDS ee eee scalar float values), and 


"componenttType": 
Tee aee tl the total element count. 


5126, 


The sparse data block 
contains the count of 
Sparse data elements. 


"sparse": { 
“eount.”' + 4: 


"values": { 
"bufferView": 


}, 


The values refer to the 
bufferView that contains 
the sparse data values. 


2, 


"indices": { 
"bufferView": 1, 
"componenttType": 


The target indices for 
the sparse data values 
i are defined with a 
} reference toa 
] bufferView and the 
componenttType. 


5123 


The values are written into the final accessor data, 
at the positions that are given by the indices: 


sparse (count=4) 


4.3]9.1]5.2}2.7 


values 


indices 


0 1 2 3 4 5 6 7 8 9 
}0.0]4.3]0.0}0.0}9.1]5.2/0.0]2.7/0.0]0.0| 


Final accessor data with 10 float values 


24 28 32 

This data may, for example, 
be used by a mesh primitive, 
to access 2D texture 
coordinates: The data of the 
bufferView may be bound 
as an OpenGL buffer, using 
glBindBuffer. Then, the 
properties of the accessor 
may be used to define this 
buffer as vertex attribute 
data, by passing them to 
glVertexAttribPointer 
when the bufferView buffer 
iS bound. 


24 28 32 


24 28 32 
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materials 


Each mesh primitive may refer to one of the materials that are 
contained in a gITF asset. The materials describe how an object 
Should be rendered, based on physical material properties. This 
allows to apply Physically Based Rendering (PBR) techniques, 
to make sure that the appearance of the rendered object is 
consistent among all renderers. 


The default material model is the Metallic-Roughness-Model. 
Values between 0.0 and 1.0 are used to describe how much the 
material characteristics resemble that of a metal, and how rough 
the surface of the object is. These properties may either be 


given as individual values that apply to the whole object, or be 00 0.25 05 0.75 1.0 
read from textures. Metal > 


Roughness 


"materials": [ The properties that define a material in the Metallic-Roughness-Model 


{ are summarized in the pbrMetallicRoughness object: 
"“pbrMetallicRoughness": { 


"baseColorTexture": { The baseColorTexture is the main texture that will be applied to the 
cosas Poa object. The baseColorFactor contains scaling factors for the red, green, 
"texCoord": 1 ; 

; blue and alpha component of the color. If no texture is used, these 

easecolarractori: values will define the color of the whole object. 

[lO ois, Ofs5, 280 1: The metallicRoughnessTexture contains the metalness value in 

"metallicRoughnessTexture": { the "blue" color channel, and the roughness value in the "green" color 
"index": 5, . anes 
eee ricer channel. The metallicFactor and roughnessFactor are multiplied 

1, with these values. If no texture is given, then these factors define 


"metallicFactor": 1.0, the reflection characteristics for the whole object. 
"roughnessFactor": 0.0, 
} In addition to the properties that are defined via the Metallic-Roughness- 
"normalTexture": { Model, the material may contain other properties that affect the object 
cams aa appearance: 
"andex": 2, 
"texCoord": 1 e The normalTexture refers to a texture that contains tangent-space 


}, normal information, and a scale factor that will be applied to these 
"occlusionTexture": { normals 


"strength": 0.9, : 
"index": 4, The occlusionTexture refers to a texture that defines areas of the 


"texCoord": 1 Surface that are occluded from light, and thus rendered darker. This 
a information is contained in the "red" channel of the texture. The 
"emissiveTexture": { . ‘ : : 

Maindex a) occlusion strength Is a scaling factor to be applied to these values. 


"texCoord": 1 The emissiveTexture refers to a texture that may be used to 
eee ve illuminate parts of the object surface: It defines the color of the 
emissiveFactor": : : a 

[0.4, 0.8, 0.6] light that is emitted from the surface. The emissiveFactor contains 


} scaling factors for the red, green and blue components of this texture. 
], 


Material properties in textures 


The texture references in a material always 
"meshes": [ "materials": [ contain the index of the texture. They may 
{ = also contain the texCoord set index. This 


i amil [ PP eer is the number that determines the 
"name": "brushed gold", i 
er ae ee ee ee TEXCOORD <n> attribute of the rendered 


"attributes": { "baseColorFactor": mesh primitive that contains the texture 
"NORMAL": 3, [1,1,1,1], coordinates for this texture, with 0 being 
"POSITION": 1, "baseColorTexture": { the default 
"TEXCOORD : "index" : 1, 

" TEXCOO wtexCoord" : "textures": [ 
}, 


"metallicFactor": 1.0, 
"roughnessFactor": 1.0 "Source": 4, 
"sampler": 2 
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cameras 


Each of the nodes may refer to one of the cameras 
that are defined in the gITF asset. 


"cameras": [ 


There are two types of 
"type": "perspective", 
Tpetepece ivan cameras: perspective 
"aspectRatio": 1.5, and orthographic 
"yfov": 0.65, ones, and they define 
peer eer the projection matrix. 
"Znear": 0.01 
i}, The value for the far 
clipping plane distance 

“ type": ‘orthographic’, of a perspective camera, 

een zfar, is optional. When 
ccanay 1.0, it is omitted, the camera 
"2far": 100, uses a special projection 
"znear": 0.01 matrix for infinite 


projections. 


When one of the nodes refers to a camera, then 
an instance of this camera Is created. The camera 
matrix of this instance is given by the global 
transform matrix of the node. 


textures, images, samplers 


The textures contain information about textures 
that may be applied to rendered objects: Textures 
are referred to by materials to define the basic 
color of the objects, as well as physical properties 
that affect the object appearance. 


peexcures, si The texture consists of a 
{ reference to the source of 


"source": 4, : : 
Seameler ts the texture, which is one of 


} the images of the asset, and 


a reference to a sampler. 


"images": [ 


data used for the texture. 

This data can be given via 
Se eee a URI that is the location of 

an image file, or by a 
"bufferView": 3, reference to a bufferView 
"mimeType" : and a MIME type that 


"image/jpeg" defines the type of the image 


data that is stored in the 


Ie 
buffer view. 


(eas heen || The samplers describe the 
< wrapping and scaling of 
9729, textures. (The constant 
"minFilter": 9987, values correspond to 
PESTS 3 LOOT 5 OpenGL constants that 


"magFilter": 


"wrapT": 10497 ) 
gael can directly be passed to 


glTexParameter). 
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The images define the image 


Page 5 


skins 

A gITF asset may contain the information that is 
necessary to perform vertex skinning. With vertex 
Skinning, it is possible to let the vertices of a mesh 
be influenced by the bones of a skeleton, based on 


its current pose. 
? A node that refers to a mesh 
nodes": [ 


{ may also refer to a skin. 


"name": Wekans'' = [ 


"Skinned mesh node", 
"mesh": O > "inverseBindMatrices": 12, 
> UU; VIOUS iw lee oe | 


} 
], 
"name": "Torso", The skins contain an array 
"children": of joints, which are the 
! ae ed | indices of nodes that define 
"rotation": eee : 
Tegade’ [ ah. the skeleton hierarchy, and 
Uepaneietiont Pou the inverseBindMatrices, 
ey which is a a reference to an 
an accessor that contains one 


"name": "Legh", matrix for each joint. 


UCase LE Le The skeleton hierarchy is 

a modeled with nodes, just 
like the scene structure: 
Each joint node may have a 

SUES 5 UNUISSRETN™ local transform and an array 

of children, and the "bones" 

of the skeleton are given 


Il 3 implicitly, as the connections 
=~ & between the joints. 

The mesh primitives of a 
Skinned mesh contain the 
POSITION attribute that 
refers to the accessor for the 
vertex positions, and two 
special attributes that are 
required for skinning: 
A JOINTS 0 and a WEIGHTS 0 
attribute, each referring to 
an accessor. 


The JOINTS 0 attribute data 

contains the indices of the 

joints that should affect the 

vertex. 

The WEIGHTS 0 attribute data 
eehes i! defines the weights indicating 
er ey how strongly the joint should 

{ influence the vertex. 


"attributes": wee 
Sea ea From this information, the 


{ 
“gomnts 0": 1, Skinning matrix can be 
"WEIGHTS 0": 2. computed. 


} 


FootR FootL 


This is explained in detail in 
“Computing the skinning 
matrix". 
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Computing the skinning matrix 


The skinning matrix describes how the vertices of a mesh are transformed based on the current pose of a 
Skeleton. The skinning matrix is a weighted combination of joint matrices. 


Computing the joint matrices 


The skin refers to the inverseBindMatrices. This | For each node whose index appears in the joints of 
is an accessor which contains one inverse bind the skin, a global transform matrix can be computed. 
matrix for each joint. Each of these matrices It transforms the mesh from the local space of the 
transforms the mesh into the local space of the joint, based on the current global transform of the 
joint. joint, and is called globalJointTransform. 
inverseBindMatrix[1] 
From these matrices, a jointMatrix may be 
computed for each joint: 
jointMatrix[j] = 
inverse(globalTransform) * 


globalJointTransform[j] * 
inverseBindMatrix[j] ; 


Any global transform of the node that contains 
the mesh and the skin is cancelled out by 
pre-multiplying the joint matrix with the inverse 
of this transform. 


For implementations based on OpenGL or WebGL, 
the jointMatrix array will be passed to the 


vertex shader as a uniform. globalJointTransform[1] 


Combining the joint matrices to create the skinning matrix 


The primitives of a skinned mesh contain the POSITION, Vertex Shader 
JOINT and WEIGHT attributes, referring to accessors. uniform mat4 u_jointMatrix[12] ; 


These accessors contain one element for each vertex: attribute vec4 ey 


attribute vec4 a jc 
POSITION JOINTS 0 WEIGHTS 0 


attribute vec4 aRyETEEE 
wooo Peel) BELT 


gong main(void) { 


mat4 skinMatrix = 
a _weight.x * u_jointMatrix[int(a_ joint.x)] + 
The data of these accessors Is passed as attributes to a_weight.y * u_jointMatrix[int(a_joint.y)] + 


* 
: ae , a _weight.z * u_jointMatrix[int(a_ joint.z)] + 
the vertex shader, together with the jointMatrix array. Sr edane aie scme nae ne Geneon 


In the vertex shader, the skinMatrix is computed. It is gl_Position = 

a linear combination of the joint matrices whose indices aa are a 
are contained in the JOINTS_0 attribute, weighted with 

the WEIGHTS 0 values: 


: ; oe skinMatrix 1.0 * jointMatrix[1] jointMatrix[0] 
The skinMatrix goes 


transforms the “ ox skinMatrix = 0.75 * jointMatrix[1] jointMatrix[0] 


joint2 


vertices based on ey . 
the skeleton pose, 4 o~<- skinMatrix = 0.5 * jointMatrix[1] jointMatrix[0] 
before they are : 
transformed with oe: siete: 
the model-view- 
perspective matrix. ! jointo | 

Q@<& skinMatrix ).0 * jointMatrix[1) jointMatrix[0] 


* JointMatrix[1] jointMatrix [0] 


Wiki page about skinning in COLLADA: https://www.khronos.org/collada/wiki/Skinning (The vertex skinning in COLLADA 
Section 4-7 in the COLLADA specification: https://www.khronos.org/files/collada spec 1 _5.pdf Is Similar to that in gITF) 
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animations 


A gITF asset can contain animations. An animation can be applied to the properties of a node that define 
the local transform of the node, or to the weights for the morph targets. 


(enane Nene Each animation consists of two elements: An array of channels and an 
{ array of samplers. 


"channels": [ 


; Each channel defines the target of the animation. This target usually 
Trees refers to a node, using the index of this node, and to a path, which 
"node": 1, is the name of the animated property. The path may be "translation", 
path cone lation: "rotation" or "scale", affecting the local transform of the node, or 
"sampler": 0 "weights", in order to animate the weights of the morph targets of 
the meshes that are referred to by the node. The channel also refers 


to a sampler, which summarizes the actual animation data. 


A sampler refers to the input and output data, using the indices of 
accessors that provide the data. The input refers to an accessor with 
"interpolation": "LINEAR", scalar floating-point values, which are the times of the key frames of 
ae ool the animation. The output refers to an accessor that contains the 
1 values for the animated property at the respective key frames. The 
} Sampler also defines an interpolation mode for the animation, which 
] may be "LINEAR", "STEP", or "CUBICSPLINE". 


Animation samplers 
During the animation, a "global" animation time (in seconds) is advanced. 


0 6 
Global time: 


The data of the input accessor 
of the animation sampler, 
containing the key frame times 


The sampler looks up the key frames for 
the current time, in the input data. 


The data of the output accessor The corresponding values of the output 
of the animation sampler, data are read, and interpolated based on 


cleviee Mallnle) gal soy We no YSU the interpolation mode of the sampler. 
for the animated property 


Animation channel targets Animating the weights for the morph targets that 
The interpolated value that is provided by an are defined for the primitives of a mesh that is 
animation sampler may be applied to different attached to a node: 

animation channel targets. Original mesh 

primitive attribute 


Displacement for "POSITION" Displacement for 
translation=[2, 0, 0] translation=[3, 2, 0] "POSITION" from "POSITION" from 


morph target 0: morph target 1: 


Animating the translation of a node: 


o* ~ 


® 
% 
e 
eo @° 


¢ 
¢ 
o 
a 


Animating the rotation of a skeleton node of a skin: 


rotation= rotation= ; 
[0.0, 0.0, 0.0, 1.0] [0.0, 0.0, 0.38, 0.92] Rendering 


weights= weights= 
[0.5,0.0 [0.0,0.5] 
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Binary gITF files 


In the standard gITF format, there are two options To overcome these drawbacks, there is the option 
for including external binary resources like buffer to combine the gITF JSON and the binary data into 
data and textures: They may be referenced via a single binary gITF file. This is a little-endian file, 
URIs, or embedded in the JSON part of the gITF with the extension ".glb". It contains a header, 
using data URIs. When they are referenced via URIs, which gives basic information about the version 
then each external resource implies a new and structure of the data, and one or more 
download request. When they are embedded as chunks that contain the actual data. The first 
data URIs, the base 64 encoding of the binary data chunk always contains the JSON data. The 

will increase the file size considerably. remaining chunks contain the binary data. 


12-byte header chunk 0 (JSON) chunk 1 (Binary Buffer) 
rN 


magic version length chunkLength]| chunkType chunkData |chunkLength]| chunkType chunkData a 
uint32 uint32 uint32 uint32 uint32 uchar[] uint32 uint32 uchar [] 
LO LS 
The magic entry has the value 0x46546C6/7, The chunkLength is the length of the chunkData, in bytes 


which is the ASCII string "gl TF". This is used ee | : 
to identify the data as a binary gITF The chunkType value defines what type of data is contained in the chunkData. 
eT | It may be Ox4E4F534A, which is the ASCII string "JSON", for JSON data, or 
The version defines the file format version. 0x004E4942, which is the ASCII string "BIN", for binary data. 


The version described here is version 2 : 
The chunkData contains the actual data of the chunk. This may be 
The length is the total length of the file, in bytes the ASCII representation of the JSON data, or binary buffer data. 


Extensions 


The gITF format allows extensions to add new ae Extensions allow adding 
functionality, or to simplify the definition of a arbitrary objects in the 
commonly used properties. "extensions" : { extensions property of 


ee "KHR_ lights_common" : { other objects. 
When an extension is used "extensionsUsed" : [ "lightSource" : true, The name of such an 


in a gITF asset, it has to be "KHR_lights_common", hy 
listed in the top-level "CUSTOM EXTENSION" "CUSTOM EXTENSION" : { object = the 2elS ee the 


. ] "customProperty" C name of the extension, 
extensionsUsed property. 


"customValue" 
The extensionsRequired — extensionsRequired" : ae. oc coe 
property lists the extensionS "KHR_lights_common" aaajsertles. 
that are strictly required to! 
properly load the asset. 


Existing extensions 
The following extensions are developed and maintained on the Khronos GitHub repository: 


e Specular-Glossiness Materials 
https://github.com/KhronosGroup/gITF/tree/master/extensions/2.0/Khronos/KHR_materials_pbrSpecularGlossiness 
This extension Is an alternative to the default Metallic-Roughness material model: It allows to define 
the material properties based on specular and glossiness values. 
Unlit Materials 
https://github.com/KhronosGroup/gITF/tree/master/extensions/2.0/Khronos/KHR_materials unlit 
This extension allows the definition of materials for which no physically based lighting computations 
Should be performed. 
Punctual Lights 
https://github.com/KhronosGroup/gITF/tree/master/extensions/2.0/Khronos/KHR_lights_ punctual 
This extension allows adding different types of lights to the scene hierarchy. This refers to point lights, 
spot lights and directional lights. The lights can be attached to the nodes of the scene hierarchy. 


WebGL Rendering Techniques 
https://github.com/KhronosGroup/gITF/tree/master/extensions/2.0/Khronos/KHR_techniques_ webg| 

With this extension, it is possible to define GLSL shaders that should be used for rendering the 
gITF asset in OpenGL or WebGL 

Texture transforms 
https://github.com/KhronosGroup/gITF/tree/master/extensions/2.0/Khronos/KHR_texture_transform 

This extension allows defining offset, rotation, and scaling for textures, so that multiple textures 
can be combined in order to create a texture atlas 
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